RFC 5234
Augmented BNF for Syntax Specifications: ABNF
構文詳述のための拡張BNF: ABNF
このメモのステータス
この文書は、インターネットコミュニティ向けにインターネット標準化過程のプロトコルを規定し、改善のための議論と提案を求めています。このプロトコルの標準化状況とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
概要
インターネット技術仕様では、形式的な構文を定義する必要があることがよくあります。長年にわたり、Backus-Naur Form (BNF) の修正版である Augmented BNF (ABNF) は、多くのインターネット仕様で広く用いられてきました。本仕様では ABNF について規定しています。ABNF は、簡潔さと簡潔さを、適切な表現力とバランスよく両立させています。標準 BNF と ABNF の違いは、命名規則、繰り返し、選択肢、順序依存性、値の範囲などです。本仕様では、いくつかのインターネット仕様で共通するタイプのコア語彙解析器のための追加規則定義とエンコーディングも提供しています。
1. はじめに
インターネット技術仕様では、多くの場合、正式な構文を定義する必要があり、作成者が有用と考える記法を自由に採用することができます。長年にわたり、Backus-Naur Form (BNF) の修正版である Augmented BNF (ABNF) は、多くのインターネット仕様で普及してきました。ABNF は、簡潔さと単純さを適切な表現力と両立させています。Arpanet の初期には、各仕様が独自の ABNF 定義を含んでいました。これには電子メール仕様 RFC733 、そして RFC822 が含まれ、これらは ABNF を定義するための一般的な引用文献となりました。本文書では、これらの定義を分離することで、選択的な参照を可能にしています。当然のことながら、いくつかの変更と機能拡張も提供しています。 標準 BNF と ABNF の違いは、命名規則、繰り返し、選択肢、順序非依存、値の範囲などです。付録 B では、いくつかのインターネット仕様に共通するタイプのコア語彙解析器の規則定義とエンコーディングを示します。これは便宜上提供されており、このドキュメントの本文で定義されているメタ言語とは別のものであり、正式なステータスとも異なります。
2. ルール定義
2.1. ルールの命名
ルール名は、単に名前そのものであり、アルファベットで始まり、アルファベット、数字、ハイフン（ダッシュ）の組み合わせが続く文字列です。
注:
ルール名は大文字と小文字を区別しません。
<rulename>、<Rulename>、<RULENAME>、<rUlENamE> という名前はすべて同じルールを指します。
オリジナルの BNF とは異なり、山括弧 ("<", ">") は必須ではありません。ただし、ルール名の用途を区別するために山括弧を使用することもできます。これは通常、自由形式の文章におけるルール名の参照、または以下の繰り返しの説明に示すように、空白で区切られていない文字列に結合された部分的なルールを区別する場合に限定されます。
2.2. 規則の形式
規則は以下のシーケンスで定義されます。
name = elements crlf
<name> は規則の名前、<elements> は1つ以上の規則名または終端記号、<crlf> は行末指示子（キャリッジリターンに続いてラインフィード）です。等号は規則名と規則の定義を区切ります。要素は、1つ以上の規則名および／または値定義のシーケンスを形成し、このドキュメントで定義されている様々な演算子（代替演算子や繰り返し演算子など）に従って組み合わせられます。
見やすさを考慮して、規則定義は左揃えで記述します。規則が複数行にわたる場合、継続行はインデントされます。左揃えとインデントは、ABNF規則の最初の行を基準としており、ドキュメントの左マージンと一致する必要はありません。
2.3. 終端値 Terminal Values
規則は終端値の文字列（文字と呼ばれることもあります）に解決されます。ABNFでは、文字は単なる非負の整数です。特定のコンテキストでは、値から文字セット（ASCIIなど）への特定のマッピング（エンコーディング）が指定されます。
終端は1つ以上の数字文字で指定され、それらの文字の基数解釈が明示的に示されます。現在、以下の基数が定義されています。
b = 2進数
d = 10進数
x = 16進数
したがって、
CR = %d13
CR = %x0D
はそれぞれ、キャリッジリターンのUS-ASCIIの10進数と16進数表現を指定します。 このような値の連結文字列は、ピリオド（「.」）を使用して値内の文字の区切りを示すことで簡潔に指定されます。したがって、次のようになります。
CRLF = %d13.10
ABNFでは、引用符で囲んだリテラルテキスト文字列を直接指定できます。したがって、次のようになります。
command = "command string"
リテラルテキスト文字列は、連結された印刷可能文字の集合として解釈されます。
注:
ABNF文字列は大文字と小文字を区別せず、これらの文字列の文字セットはUS-ASCIIです。
したがって、次のようになります。
rulename = "abc"
および次のようになります。
rulename = "aBc"
は、「abc」、「Abc」、「aBc」、「abC」、「ABc」、「aBC」、「AbC」、「ABC」に一致します。
大文字と小文字を区別するルールを指定するには、文字を個別に指定します。
例えば、
rulename = %d97 %d98 %d99
または
rulename = %d97.98.99
は、小文字の abc のみで構成される文字列にのみ一致します。
2.4. 外部エンコーディング
終端値文字の外部表現は、保存環境や伝送環境の制約によって異なります。そのため、同じABNFベースの文法でも、7ビットUS-ASCII環境用、バイナリオクテット環境用、そして16ビットUnicodeを使用する場合はさらに異なるエンコーディングなど、複数の外部エンコーディングが存在する場合があります。エンコーディングの詳細はABNFの範囲外ですが、付録Bでは、インターネットの多くの場所で一般的に使用されている7ビットUS-ASCII環境の定義を示しています。
外部エンコーディングを構文から分離することで、同じ構文に対して異なるエンコーディング環境を使用できるようになります。
3. 演算子
3.1. 連結: ルール1 ルール2
ルールは、一連のルール名を列挙することで、単純で順序付けられた値の文字列（つまり、連続する文字の連結）を定義できます。例:
foo = %x61 ; a
bar = %x62 ; b
mumble = foo bar foo
つまり、ルール <mumble> は小文字の文字列 "aba" に一致します。
線形空白: 連結はABNF構文解析モデルの中核です。連続する文字（値）の文字列は、ABNFで定義された規則に従って解析されます。インターネット仕様では、区切りの特殊文字やアトミック文字列など、主要な構成要素の周囲に線形空白（スペースと水平タブ）を自由に暗黙的に散在させることが認められてきた歴史があります。
注:
このABNF仕様は、線形空白の暗黙的な指定を規定していません。
区切り文字や文字列セグメントの周囲に線形空白を許容する文法は、明示的に指定する必要があります。このような空白を「コア」ルールに定義し、それを上位レベルのルールで様々な用途に用いることは、多くの場合有用です。「コア」ルールは、字句解析器に組み込まれることもあれば、単にメインルールセットの一部となることもあります。
3.2. 代替: ルール1 / ルール2
スラッシュ ("/") で区切られた要素は代替です。
したがって、
foo / bar
は <foo> または <bar> を受け入れます。
注:
引用符で囲まれたアルファベット文字を含む文字列は、代替文字を指定するための特別な形式であり、大文字と小文字の混在を問わない、指定された順序で含まれる文字の組み合わせ文字列の集合を表す非終端記号として解釈されます。
3.3. 漸進的な代替：Rule1 =/ Rule2
代替のリストを断片的に指定すると便利な場合があります。つまり、最初のルールが1つ以上の代替に一致し、後続のルール定義で代替セットに追加されていくというものです。これは、パラメータリストなどでよくあるように、同じ親ルールセットから派生した、本来は独立した仕様の場合に特に便利です。ABNFでは、以下の構文によってこの漸進的な定義が可能です。
oldrule =/ additional-alternatives
つまり、ルールセット
ruleset = alt1 / alt2
ruleset =/ alt3
ruleset =/ alt4 / alt5
は、
ruleset = alt1 / alt2 / alt3 / alt4 / alt5
と指定するのと同じです。
3.4. 値の範囲の代替: %c##-##
数値の範囲は、ダッシュ ("-") を使用して簡潔に指定できます。
つまり、次のようになります。
DIGIT = %x30-39
は次の式と同等です。
DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
"7" / "8" / "9"
連結された数値と数値の範囲を同じ文字列内に指定することはできません。数値は、連結にドット表記を使用することも、1つの値の範囲を指定するためにダッシュ表記を使用することもできます。したがって、行末シーケンスの間に1つの印刷可能文字を指定するには、次の式を使用します。
char-line = %x0D.0A %x20-7E %x0D.0A
3.5. シーケンスグループ: (Rule1 Rule2)
括弧で囲まれた要素は単一の要素として扱われ、その内容は厳密に順序付けられます。したがって、
elem (foo / bar) blat
は (elem foo blat) または (elem bar blat) に一致し、
elem foo / bar blat
は (elem foo) または (bar blat) に一致します。
注:
選択肢が複数のルール名またはリテラルで構成される場合、「裸の」代替の正しい読み方に頼るのではなく、グループ化表記を使用することを強くお勧めします。
したがって、次の形式を使用することを推奨します。
(elem foo) / (bar blat)
これにより、一般の読者による誤解を回避できます。
シーケンスグループ表記は、自由記述内で要素シーケンスを文章から区別するためにも使用されます。
3.6. 変数の繰り返し: *規則
要素(element)の前にある演算子「*」は繰り返しを表します。完全な形式は次のとおりです。
<a>*<b>element
ここで、<a>と<b>はオプションの10進数値で、elementが少なくとも<a>回、最大<b>回出現することを示します。
デフォルト値は0と無限大です。つまり、*<element>は0を含む任意の回数を許容します。1*<element>は少なくとも1回出現する必要があります。
3*3<element>はちょうど3回を許容します。1*2<element>は1回または2回を許容します。
3.7. 特定の繰り返し: nRule
次の形式の規則:
<n>element
は、
<n>*<n>element
つまり、<element> がちょうど <n> 回出現することを意味します。したがって、2DIGIT は2桁の数字、3ALPHA は3文字のアルファベット文字列です。
角括弧はオプションの要素シーケンスを囲みます:
[foo bar]
は
*1(foo bar)
と同等です。
3.9. コメント: ; コメント
セミコロンで始まるコメントは行末まで続きます。これは、仕様と並行して役立つ注釈を記述する簡単な方法です。
3.10. 演算子の優先順位
上記で説明した様々なメカニズムには、以下の優先順位があります。上から下へ、最も高い優先順位（最も強い結合）から最も低い優先順位（最も緩い結合）までです。
ルール名、prose-value、終端値
コメント
値の範囲
繰り返し
グループ化、オプション
連結
代替演算子
代替演算子を連結演算子と自由に組み合わせて使用すると、混乱を招く可能性があります。
繰り返しますが、連結グループを明示的に作成するには、グループ化演算子を使用することをお勧めします。
4. ABNF における ABNF の定義
注記:
1. この構文では、比較的厳密な規則のフォーマットが求められます。そのため、仕様に含まれる規則セットのバージョンによっては、ABNF パーサーで解釈できるように前処理が必要になる場合があります。
2. この構文では、付録 B に示されている規則を使用します。
code:ABNF
rulelist = 1*( rule / (*c-wsp c-nl) )
rule = rulename defined-as elements c-nl
; continues if next line starts
; with white space
rulename = ALPHA *(ALPHA / DIGIT / "-")
defined-as = *c-wsp ("=" / "=/") *c-wsp
; basic rules definition and
; incremental alternatives
elements = alternation *c-wsp
c-wsp = WSP / (c-nl WSP)
c-nl = comment / CRLF
; comment or newline
comment = ";" *(WSP / VCHAR) CRLF
alternation = concatenation
*(*c-wsp "/" *c-wsp concatenation)
concatenation = repetition *(1*c-wsp repetition)
repeat = 1*DIGIT / (*DIGIT "*" *DIGIT)
element = rulename / group / option /
char-val / num-val / prose-val
group = "(" *c-wsp alternation *c-wsp ")"
option = "*c-wsp alternation *c-wsp ""
char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE
; quoted string of SP and VCHAR
; without DQUOTE
num-val = "%" (bin-val / dec-val / hex-val)
bin-val = "b" 1*BIT
; series of concatenated bit values
; or single ONEOF range
dec-val = "d" 1*DIGIT
hex-val = "x" 1*HEXDIG
prose-val = "<" *(%x20-3D / %x3F-7E) ">"
; bracketed string of SP and VCHAR
; without angles
; prose description, to be used as
; last resort
5. セキュリティに関する考慮事項
セキュリティは、この文書とは無関係であると考えられます。
6. 参考文献
6.1. 規範的参考文献
US-ASCII 米国規格協会、「符号化文字セット - 7ビット情報交換用米国標準コード」、ANSI X3.4、1986年。 6.2. 参考文献
RFC 733 Crocker, D.、Vittal, J.、Pogran, K.、およびD. Henderson、「ARPAネットワークテキストメッセージ形式の標準」、RFC 733、1977年11月。 RFC 822 Crocker, D.、「ARPAインターネットテキストメッセージ形式の標準」、STD 11、RFC 822、1982年8月。 付録A. 謝辞
ABNFの構文は、元々RFC 733で規定されていました。SRI InternationalのKen L. Harrenstien氏は、BNFを拡張BNF（Augmented BNF）に再コーディングし、表現を小さく分かりやすくする作業を担当しました。
この最近のプロジェクトは、電子メール仕様書作成者以外の人々によって繰り返し引用されているRFC 822の一部、すなわち拡張BNFの記述を削ぎ落とすという単純な作業から始まりました。ワーキンググループは、既存のテキストを単純に盲目的に別の文書に変換するのではなく、既存の仕様と過去15年間に公開された関連仕様の利点だけでなく、欠点も慎重に検討し、改良を進めることを選択しました。これにより、このプロジェクトは当初の意図よりもかなり野心的なものとなりました。興味深いことに、リスト記法の削除などの決定は予想外でしたが、結果は当初のものと大きく変わりませんでした。
この「分離」版の仕様はDRUMSワーキンググループによって作成され、Jerome Abela、Harald Alvestrand、Robert Elz、Roger Fajman、Aviva Garrett、Tom Harsch、Dan Kohn、Bill McQuillan、Keith Moore、Chris Newman、Pete Resnick、そしてHenning Schulzrinneらから多大な貢献を受けました。
ドラフト標準版をXMLソース形式に変換してくださったJulian Reschke氏には、特に感謝申し上げます。
付録B. ABNFのコアABNF
この付録には、一般的に使用されるいくつかの基本ルールが含まれています。基本ルールは大文字で表記されています。これらのルールは、7ビットASCIIまたは7ビットASCIIのスーパーセットである文字セットでエンコードされたABNFにのみ有効であることに注意してください。
B.1. コアルール
SP、HTAB、CRLF、DIGIT、ALPHA など、一部の基本ルールは大文字で表記されます。
code:Core
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
BIT = "0" / "1"
CHAR = %x01-7F
; any 7-bit US-ASCII character,
; excluding NUL
CR = %x0D
; carriage return
CRLF = CR LF
; Internet standard newline
CTL = %x00-1F / %x7F
; controls
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (Double Quote)
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB = %x09
; horizontal tab
LF = %x0A
; linefeed
LWSP = *(WSP / CRLF WSP)
; Use of this linear-white-space rule
; permits lines containing only white
; space that are no longer legal in
; mail headers and have caused
; interoperability problems in other
; contexts.
; Do not use when defining mail
; headers and use with caution in
; other contexts.
OCTET = %x00-FF
; 8 bits of data
SP = %x20
VCHAR = %x21-7E
; visible (printing) characters
WSP = SP / HTAB
; white space
B.2. 共通エンコーディング
外部的には、データは「ネットワーク仮想ASCII」（つまり、8ビットフィールド内の7ビットUS-ASCII）として表現され、上位（8番目）ビットは0に設定されます。値の文字列は「ネットワークバイトオーダー」で表され、上位バイトが左側に配置され、ネットワーク上で最初に送信されます。
著者のアドレス
Dave Crocker（編集者）
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale, CA 94086
米国
電話: +1.408.246.8253
Eメール: dcrocker@bbiw.net
Paul Overell
THUS plc.
1/2 Berkeley Square,
99 Berkeley Street
Glasgow G3 7HR
英国
Eメール: paul.overell@thus.net
完全な著作権表示
Copyright (C) The IETF Trust (2008).
本文書は、BCP 78 に定められた権利、ライセンス、および制限事項の対象であり、BCP 78 に明記されている場合を除き、著者はすべての権利を留保します。
この文書およびここに含まれる情報は「現状有姿」で提供され、寄稿者、寄稿者が代表する組織または後援する組織（存在する場合）、インターネット協会、IETF トラスト、およびインターネット エンジニアリング タスク フォースは、明示的または黙示的を問わず、ここに含まれる情報の使用がいかなる権利も侵害しないという保証、または商品性または特定目的への適合性に関する黙示的な保証を含むがこれに限定されない、一切の保証を否認します。
知的財産権
IETFは、本文書に記載されている技術の実装または使用に関連して主張される可能性のある知的財産権その他の権利の有効性または範囲、あるいはかかる権利に基づくライセンスが利用可能かどうかについて、いかなる立場も表明しません。また、IETFがかかる権利を特定するための独自の努力を行ったことを表明するものでもありません。RFC文書における権利に関する手続きに関する情報は、BCP 78およびBCP 79に記載されています。
IETF事務局に開示された知的財産権（IPR）のコピー、および利用可能となるライセンスの保証、あるいは本仕様の実装者または利用者によるかかる所有権の使用に関する一般的なライセンスまたは許可の取得を試みた結果は、IETFオンラインIPRリポジトリ（ http://www.ietf.org/ipr ）から入手できます。 IETFは、本標準の実装に必要な技術に適用される可能性のある著作権、特許、特許出願、またはその他の所有権について、関係者の皆様にご報告いただくようお願いしています。情報は IETF（ietf-ipr@ietf.org）までお送りください。